こんにちは、LIFULL HOME'Sのネイティブアプリ開発チームでエンジニアリングマネージャーをしている佐々木です。 「この画面、何が表示されてるか教えてもらえますか？」 目の前のタスクに集中しているときにSlackに飛んでくるこの一文で、エンジニアの手は止まります。悪気はない。でもチームのリードタイムは確実に伸びていく。 この問題を、AIに業務知識を構造化して渡すことで解消した話をします。 背景：人間が"コンテキストの運び屋"になっていた 試行錯誤：最初からこの形だったわけではない 何を作ったか：業務知識をパッケージ化する なぜ効いたか：3つの設計判断 ① 定義の集約：誰がいつ聞いても同じ答えが返る ② スキル化：「やりたいこと」を伝えるだけで手順が走る ③ ツール統合：分析もチケット起票も1箇所で完結 成果：「聞く側」も「聞かれる側」も変わった 余談：世界では「コンテキストレイヤー」と呼ばれているらしい まとめ 背景：人間が"コンテキストの運び屋"になっていた 私たちのチームでは、メイン施策を進めている最中に、次の施策のための質問・相談が頻繁に飛んできていました。 PdMから：「この画面の表示ロジックってどうなってる？」 デザイナーから：「この機能、実装上の制約ある？」「この表現はコード的に可能？」 マーケから：「この数値、どのイベントで計測されてる？」 エンジニアは手を止めてコードを読み、回答する。1往復30分〜数時間。これが毎日何回も発生していました。 問題はそれだけではありません。質問する側も「エンジニアの手を止めてしまう」という心理的ハードルを感じていて、遠慮して質問を溜め込む → まとめて聞く → 大量の回答待ちが発生する、という悪循環もありました。 本質は明確でした。 チームの業務知識が人の頭にしかなく、AIが参照できる形になっていなかった 。 試行錯誤：最初からこの形だったわけではない 前提として、利用者は非エンジニアです。GitHubアカウントを持っていない人がほとんどで、 git clone もターミナルも使えない。この制約の中で、どうやってコードベースの知識をAIに渡すか。 最初に試したのはGoogle GeminiのGem（カスタムAI）+ GitHub連携でした。でも連携した本人しか使えず、チームには共有できない。NotebookLMも同じ問題。 Repomix （コードを1ファイルに圧縮するツール）も試しましたが、ディレクトリ構造やファイル間の関係性が失われ、調査精度が出ませんでした。 結局たどり着いたのは「コードをそのまま同梱してzipで配る」という原始的な方法でした。全員が同じ環境を使えて、コードの構造もそのまま残る。「Googleドライブからダウンロード→解凍→フォルダを開く」だけで始められる。これが一番確実だった。 何を作ったか：業務知識をパッケージ化する 作ったのは、チームの業務知識を構造化してAIエージェントに渡す「パッケージ」です。zipを解凍して Kiro IDE （AIエージェント機能を内蔵したエディタ）で開き、日本語で質問するだけで使えます。 パッケージの中身は3層で構成されています。 steering（ルール・定義） : KPI定義、データソースの所在、業務上の制約 skills（手順・ナレッジ） : 分析の手順、レポート作成の方法、調査の進め方 agents（専門家） : コード調査担当、データ分析担当など、役割に特化したサブエージェント 3層構造の概念図 このしくみを、現在4チームに展開しています。 対象チーム 当初の課題 利用者 状態 ネイティブアプリ開発チーム 仕様調査でエンジニアの手が止まる PdM・企画・デザイナー ✅ 稼働中 デジタルマーケティングチーム 数値管理・レポートが手作業で属人的 マーケター ✅ 稼働中 アプリ広告運用（ASA/ASO）チーム 運用判断に専門知識が必要 企画・マーケター 🔶 一部利用 賃貸・流通領域チーム 仕様調査の横展開 PdM・企画・デザイナー 🔶 検証中 このほかにも試作段階のものがあり、少しずつ適用範囲を広げています。 このしくみの展開により、従来のコミュニケーションフローが大きく変わりました。 Before/Afterフロー比較 なぜ効いたか：3つの設計判断 ① 定義の集約：誰がいつ聞いても同じ答えが返る 「この指標の定義は？」「この計算式の出どころは？」。これまで人の頭にしかなかった情報を、Markdownファイルに一元管理しました。誰がいつ聞いても、AIが同じ定義に基づいて同じ答えを返します。属人化が構造的に解消されるしくみです。 ② スキル化：「やりたいこと」を伝えるだけで手順が走る 「着地見込を出して」と伝えるだけで、AIがデータ取得→計算→フォーマット整形まで実行します。利用者は「やりたいこと」を伝えるだけでよく、手順を知っている必要がありません。業務手順の暗黙知がスキルとして構造化されているからです。 ③ ツール統合：分析もチケット起票も1箇所で完結 BigQueryでの数値分析も、Jiraへのチケット起票も、Confluenceへの報告書投稿も、全部同じKiro IDEの中で完結します。「あの作業はスプレッドシート、この分析はGemini、あれはGoogle Apps Script」というツール跨ぎが消え、非エンジニアにとっての認知負荷が劇的に下がりました。 成果：「聞く側」も「聞かれる側」も変わった 利用者の一人である企画メンバーは、公式noteで以下のように書いてくれています。 以前は、「この仕様はどうなっていますか？」とエンジニアに確認を依頼し、その回答を待つまでに数時間〜1日ほどのリードタイムが発生していました。エンジニア側の作業を止めてしまうという心理的ハードルもありました。 しかし現在では、企画担当である私自らが調査パッケージを使い、5分〜10分程度でコードベースの一次調査を完結させています。コミュニケーションの往復が消えたことで、調査工数は約80〜90％削減され、施策検討のサイクルは圧倒的に加速しました。 — エンジニアから企画へ。LIFULL HOME'S アプリ部署で目撃した、AIシフトがもたらす「職種を越えた共創」 単に工数が減っただけではありません。「ここまで調べた結果、ここを変えれば実現できそうですが、どう思いますか？」という提案ベースの相談ができるようになったことで、意思決定の質も上がっています。 そしてエンジニア側は、調査依頼に中断されることなく、メイン施策の開発に集中できるようになりました。 余談：世界では「コンテキストレイヤー」と呼ばれているらしい ちなみに、2026年3月にa16z（米国の大手VC）が公開した記事「 Your Data Agents Need Context 」では、こう述べられています。 データ・分析エージェントは適切なコンテキストなしでは本質的に役に立たない。曖昧な質問を解きほぐすことも、ビジネス定義を解読することも、散在するデータを横断して推論することもできない。 同記事では、この問題の解決策として「企業のデータを束ね、ビジネスロジックを理解できる層をエージェントに供給する基盤」を「コンテキストレイヤー」と呼んでいます。振り返ると、私がやっていたことはまさにこれでした。 この記事を知ったのは後からです。現場の課題を解決していたら、同じ構造にたどり着いていました。 まとめ AIがどれだけ賢くなっても、チーム固有の業務知識を構造化して渡さなければ正しくは動きません。 大げさなプラットフォームがなくても、Markdownとスキル定義を整備してzipで配るだけで始められます。「人に聞く」を「AIに聞く」に変えるだけで、チームの循環は確実に変わります。 次回は、このしくみの技術的な設計と具体的なファイル構成について詳しく書く予定です。 最後に、LIFULLではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998

こんにちは。ニフティの基幹システムグループ インフラシステムチームに所属している轟木です。 担当業務はオフィス及びデータセンターのネットワーク設計・構築・運用です。 今回は、育休中に感じた家事分担のモヤモヤをきっかけに作った「家事トラッキングシステム」について紹介します。 家事はお互いにやっているはずなのに、なぜか「自分の方が多くやっている気がする」。この感覚を減らすために、Slack、Google Apps Script、Google スプレッドシート、Looker Studioを組み合わせて、家事を記録・可視化する仕組みを作りました。 背景：既存アプリが我が家に合わなかった 夫妻で同時期に育休を取ったことで、家にいる時間が増えました。すると、これまで見えにくかった家事の分担が気になるようになりました。 お互いに家事も育児もしているのに、 自分の方が家事を多くやっている気がする 相手がいつ何をしてくれたのか分かりにくい 「やった」「やっていない」が感覚ベースになり、話し合いづらい という状態になっていました。 最初は家事分担アプリも試しましたが、用意されたテンプレートが我が家の家事の粒度や負担感と合わず、記録のためだけに新しいアプリを開く習慣も定着しませんでした。 そこで、普段から使っているSlackとスプレッドシートを中心に、自分たちの生活に合わせた仕組みを作ることにしました。 Claudeに要件定義から相談した 最初にClaudeへ、改善したい点と使いたいサービス名を伝えました。 入力はできるだけ簡単にしたい 夫妻それぞれの家事をポイント化したい Slack、Google スプレッドシート、Looker Studioを使いたい 将来的にはAlexaから音声入力したい するとClaudeは、目的、スコープ、システム構成、データ設計、運用ルールまで含めた要件定義書を作ってくれました。 育児中でまとまった時間を取りづらい中でも、普段の業務ではあまり触らないSlack AppやGASまわりの設計・実装を短時間で進められました。 作ったもの 今回作った構成は次の通りです。 流れはシンプルです。Slackで家事ボタンを押すと、GASがイベントを受け取り、Google スプレッドシートにログを書き込みます。そのログをLooker Studioで集計・可視化します。 ポイントは、入力導線を「普段から開いているSlack」に寄せたことです。よく使う家事はボタンとして常に表示し、頻度が低い家事はプルダウンから選べるようにしました。 実際のSlack画面は以下のような形です。 家事をしたら、該当するボタンを押すだけで記録完了です。できるだけ考えずに入力できるようにしたことで、記録のハードルを下げられました。 工夫したところ 家事マスタをスプレッドシートで管理する 家事マスタはコードに埋め込まず、Google スプレッドシートで管理しました。 家事マスタ内の家事項目やポイントを変えたい時は、スプレッドシートを編集するだけで済みます。運用しながら家庭内ルールを調整しやすいようにしました。 ポイントは1〜5点で、作業時間だけでなく、頻度・負担感・心理的ハードルも考慮して夫妻で決めています。 ログを集計しやすい形にする 家事を記録するたびに、ログシートへ1行追加する形にしました。 ログには、日時、記録者、家事ID、家事名、ポイント、カテゴリ、入力経路を保存します。後からLooker Studioで集計しやすいように、1回の家事を1行として扱うシンプルな形にしています。 Slackボタン方式にした Slack入力は、スラッシュコマンドではなくボタン方式にしました。 スラッシュコマンドは3秒以内にレスポンスを返す必要があります。一方、GASのWebアプリはコールドスタート時に数秒かかることがあり、タイムアウトする可能性があります。 そのため、ボタン付きメッセージからGASのエンドポイントを呼び出す方式にしました。ボタン選択にすることで、家事名の表記ゆれも避けられます。 Looker Studioで可視化する 記録したログは、Looker Studioで可視化しました。 主に見ているのは、今週の家事ポイントと、どのジャンルの家事が多いかです。 ポイントで家事の大変さを完全に表せるわけではありませんが、偏りや貢献が数字で見えるだけで、感覚だけで話すより冷静に振り返れるようになりました。 導入して変わったこと 導入して一番変わったのは、「自分ばかり家事をしている」という感覚が減ったことです。 数字として見えるようになると、相手がやってくれていた家事にも気づきやすくなります。また、自分のポイントが増えると少しうれしく、家事に対するモチベーションも上がりました。 誤タップをきっかけに「押したならやるか」と実際に家事をすることもあり、記録の仕組みが行動にも少し影響するのは想定外でした。 苦労しているところ：Alexa連携 次の改善として、Alexaからの音声入力にも挑戦しています。当初はAlexaをメイン入力、Slackボタンを補助入力にする想定でしたが、現在はDeveloper Consoleのシミュレータでは動く一方で、実機ではLambdaまでリクエストが届かない状態です。 今回は完成しているSlack入力を中心に紹介しましたが、音声入力までできると、さらに記録のハードルを下げられそうです。 まとめ Claudeに要件定義から相談し、Slack、GAS、Google スプレッドシート、Looker Studioを組み合わせて、家庭内の家事トラッキングシステムを作りました。 使っている技術はどれも一般的なものです。それでも、普段の生活に合う入力導線を作り、家事を自分たちの基準で定義し、リアルタイムに可視化することで、家事分担のモヤモヤを減らすことができました。 今回の一番の学びは、AIを使うことで、既存アプリでは合わせきれなかった家庭ごとの事情を要件として整理し、自分たち用の小さな仕組みに落とし込めることです。 同じように、家庭内のタスク管理や家事分担にモヤモヤを感じている方の参考になればうれしいです。

G-gen の荒井です。当記事は Google Cloud Next '26 in Las Vegas の1日目に行われたブレイクアウトセッション「 Fast-track to Google Workspace: Smooth migration, adoption, and interoperability 」の速報レポートをお届けします。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 データ移行の課題と新しいアプローチ 従来のデータ移行における課題と役割分担 Data Import の概要と利点 今後のロードマップ ロードマップの概要 Office 編集モード Google ドキュメント Google スプレッドシート Google スライド Google Apps Script（GAS） ドライブと SharePoint Chat、Meet、Teams 戦略の転換 パワーユーザー層へのアプローチと5つのユーザー層 Foundational（一般ユーザー） Analyst（分析者） Executive（経営層） Legal（法務） Ecosystems（エコシステム） セッションの概要 当セッションでは Google Workspace へスムーズに移行するための新しいアプローチとツールが紹介されました。具体的には、インフラストラクチャを必要としない新しいデータ移行ツール「 Data Import 」や、Gemini を活用した Microsoft Office ファイルの 相互運用性の向上 、そしてレガシーな マクロの変換機能 について解説されました。 これらの機能により、移行にかかるコストと時間を大幅に削減し、ユーザーの生産性を早期に高めることが期待できます。 参考 : データ インポート ツールについて  |  Data migration  |  Google Workspace Help データ移行の課題と新しいアプローチ 従来のデータ移行における課題と役割分担 従来のシステムから Google Workspace へ移行する際、移行作業は大きな障壁となります。従来のデータ移行プロセスにおいて直面しやすい主な課題は以下の通りです。 課題 詳細 時間とコスト 従来のオンプレミス型データ移行ツールでは移行ツールのライセンス費用や移行ツールを稼働させるインフラ基盤の費用が発生し、データ移行が高額になる傾向があります。 移行速度の遅延 移行は数ヶ月に及ぶプロセスとなることが多く、そのタイムラインからビジネスオペレーションに支障をきたす可能性があります。 エラーデータ 完璧な移行ツールは存在しないため、データ損失のリスクも発生します。また不完全なデータが存在する場合、パートナーや顧客が独自のスクリプトを作成したり手動で対応したりしなければならないケースもあります。 また移行プロジェクトを進めるにあたり、以下関係者による協力が不可欠です。 関係者 役割 お客様 プロジェクトの監督およびデータ移行作業だけでなく、新しいツール導入に関する運用ルールの策定やユーザー教育を主導。 パートナー 導入計画の策定やシステム設計などプロジェクトの管理。 Google 移行を容易にするガイダンス、テクニカルサポート、および包括的なデータ移行ツールの提供。大規模で複雑な移行には、Google のプロフェッショナルサービス組織が技術的監督やアーキテクチャ支援でパートナーをサポート。 Data Import の概要と利点 Google は、クラウドネイティブな新しいデータ移行システム「 Data Import 」を発表しました。仮想マシンやクラウドインフラの構築、インストールが不要なため、従来のデータ移行に比べコスト負荷が低減されます。 特徴 詳細 ゼロコスト クラウドネイティブツールであり、仮想マシンなど追加インフラコストなしで利用可能です。 包括的なデータ移行 メール、カレンダー、連絡先などのコアデータに加え、Outlook のルール、カレンダー設定、暗号化されたコンテンツ、Microsoft Teams などの多様なデータソースやメタデータも単一のツールで移行可能です。 管理性 管理コンソールに組み込まれ、シームレスにデータ移行を実行できます。 高速な移行 特に Exchange Online からの移行において、従来のデータ移行ツールの5倍の速度を実現します。 移行計画 ソースデータ（アカウント）のスキャンからデータに基づいた正確な予測に置き換えることが可能です。また移行完了までに必要な時間の見積り（タイムライン）を算出できます。 高いスケーラビリティ 1バッチあたり最大5,000ユーザー、最大10バッチを並行して実行でき、計50,000ユーザーの同時移行が可能です。 参考 : Google Workspace Updates: Introducing data import: An easier, faster, and higher-fidelity migration to Google Workspace at no additional tool cost 今後のロードマップ ロードマップの概要 Data Import は2026年4月現在、Exchange Online からの移行において一般提供されています。今後はさらにサポート対象を拡大し、より包括的なデータ移行を実現する予定です。 今後のロードマップは以下の通り計画されています。 Q2 （4月〜6月） Exchange Online への機能追加（In-place archives、グループメールボックス、タスク、暗号化 E メール等） OneDrive と Microsoft Teams がベータ版公開 Q3 （7月〜9月） OneDrive と Microsoft Teams が一般公開 SharePoint Online のベータ版および一般公開 GCC High 環境への対応 Office 編集モード Gmail での Office 編集 （Q2 にベータ版公開予定） Gmail 上で直接 Office ファイルを編集・返信できます。 Google ドキュメント 法務向けなどの機能強化 キャプション、相互参照、行番号、スモールキャップスなどをネイティブにサポートします。 Google スプレッドシート パフォーマンスとスケール向上 セルの制限数が従来の2倍（2,000万セル）に拡張されます。 高度な分析機能 ピボットテーブルやチャート機能が強化されます。 Google スライド 埋め込みメディアサポート （2026年6月頃にベータ版公開予定） PowerPoint からインポートした際の埋め込みオーディオやビデオをサポートします。 パフォーマンス向上 （2026年6月頃にベータ版公開予定） スライドの容量制限が従来の5倍に拡張されます。 Google Apps Script（GAS） 自然言語による VBA 変換 （2026年6月頃にアルファ版公開予定） 自然言語の指示でレガシーな Excel マクロを Google Apps Script（GAS）に変換し、Google スプレッドシートで使用できるようにします。 GAS のコアサービス化 （2026年6月頃に一般公開予定） GAS が Google Workspace のコアサービスに認定され、エンタープライズグレードの信頼性、セキュリティ、コンプライアンスを満たせるようになります。 自然言語でのデバッグ （2026年6月頃にアルファ版公開予定） GAS のエラー修正が、自然言語による対話形式で可能になります。 ドライブと SharePoint 承認機能 （2026年6月頃に一般公開予定） アプリを横断したワークフローを可能にする、軽量な承認機能が搭載されます。API も実装される予定です。 Workspace Studio （一般公開済み） AI ネイティブな自動化やエージェント作成が可能であり、Microsoft Power Automate の代替手段となり得ます。 Chat、Meet、Teams Meet ハードウェア相互運用性 （一般公開済み） 1タッチで Microsoft Teams や Zoom の会議に直接参加できます。 Chat のゲストアカウント （一般公開済み） 外部ユーザーをフル機能で Chat に招待しつつガバナンスを維持できます。 戦略の転換 パワーユーザー層へのアプローチと5つのユーザー層 これまで Google は「大多数のユーザーが使いやすいこと」を重視し、一部の高度な機能を使う「パワーユーザー」は Microsoft Office などの他社製品を利用し続ける傾向にあると分析していました。 しかし、Gemini の登場によって、この考えは大きく変わりました。パワーユーザー向けの機能開発において、Google は投資をこれまでの5倍に増やし、パワーユーザーが必要とするすべての機能を Google Workspace で提供する方針へと転換しました。 単に Microsoft の機能をそのまま真似るのではなく、 変更履歴 や グラフ作成 といった基本機能から根本的に作り直しています。具体的には、以下の5つのユーザー層に向けて機能を強化していく想定が述べられました。 Foundational（一般ユーザー） Analyst（分析者） Executive（経営層） Legal（法務） Ecosystems（エコシステム） Foundational（一般ユーザー） メールで Office ファイルを共同編集するにあたり「Outlook と Word」よりも「Gmail と Google ドキュメント」の組み合わせが一番使いやすい状態を目指します。 Analyst（分析者） Google スプレッドシートのパフォーマンスを向上させ、分析者や財務部門が求める高度なデータ分析を可能にします。 パフォーマンスとスケール セルの制限数を従来の2倍（2,000万セル）に拡張（2026年4月現在、ベータ版公開済み）。さらに将来的に再度2倍にする計画があります。 高度な分析機能 ピボットテーブルやチャート機能を強化します。 Executive（経営層） Google スライドを強化し、経営層が求めるレベルの高いプレゼンテーション資料の作成に対応します。 スライドの容量制限の拡張 スライドの容量制限を従来の5倍に拡張します。 埋め込みメディアサポート Microsoft PowerPoint からインポートした際の埋め込みオーディオやビデオをシームレスにサポートします。 Legal（法務） Google ドキュメントで、法務部門に必須の厳格な文書フォーマットを完全に再現できるようにします。 法務向けフォーマット キャプション、相互参照、行番号、スモールキャップスなどをネイティブにサポートし、Word ファイルとの完璧なラウンドトリップ（Google ドキュメントで編集したデータを Microsoft Word で開いても、データやレイアウトが損なわれないことを指す）を保証します。 変更履歴の再設 2026年末までに、Microsoft Word との相互運用性を損なうことなく、変更履歴機能を根本的に再設計します。 Ecosystems（エコシステム） 外部システムと直接連携できるようにし、Microsoft 365 から Google Workspace に移行しても、これまでの業務フローを変えずに作業できるようにします。 SAP、Oracle、Litera、ServiceNow、Workday などのサードパーティ製エコシステムに、Google ドキュメント、スプレッドシート、スライドを直接組み込みます。 これらの進化により、組織の Google Workspace への移行と定着、そして新しい働き方へのトランスフォーメーションがこれまで以上に加速することが強調されました。 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 / 2026 ・Google Cloud 認定資格 7冠 ・Jagu'e'r エバンジェリスト Follow @arapote_tweet